Filecoin: 共识攻击，绝不容情
对于任何一个区块链系统而言，共识机制都是基础。一个完备的共识机制才能保证安全，高效。共识机制的设计必须要能够高效地、公平地、快速地达成共识；同时共识机制的设计需要保护诚实矿工，惩罚恶意矿工，达到维护生态的目的。Filecoin团队最近对共识机制的恶意攻击判别规则出台。本文就此做一个简单解析。
缺乏保护，攻击连发
在 go-filecoin 的0.5.7 和0.5.8 的 devnet 运行过程中，系统遭受到多次攻击。具体的一些情况我的两篇文章： Filecoin：重力攻击手法 - 关于重量之三 和 Filecoin网络：关于重量 中有比较详细的描述。但就其中的连弩攻击，虽有提及，但没有详述。在前文中，我提到，这种攻击不完全是利用重量计算设计的不足，同时也用到了共识机制的不完善的地方。这个不完善，就是还没有实现惩罚机制。
什么是连弩攻击？简单地说，就是在自己有爆块权的时候，不顾共识设计，在同一个区块高度连出多个区块。在没有惩罚机制的情况下，当前系统仅仅认定当轮此矿工有出块权即为合法，而没有对连续出块进行保护。因此，所有的出块都会被认定为合法。此攻击矿工因此可以获得多个爆块机会，也可以增加许多重量。达到攻击整个链的目的。
更多内容可以参见 go-filecoin 的 issue #3523:
共识攻击，判处死刑
由于共识机制是一条链生存的基石，那么对共识的保护就尤为重要。尤其是像 Filecoin 这样的率先采用 POS 的链，这些设计同时也是为整个区块链世界打好一个坚实的基础。
在去中心化的世界中，保护就是惩恶扬善。对于诚实矿工给予奖励，对于恶意矿工，给予必要的惩罚。其中，对于共识机制的攻击，因其牵涉到根本，惩罚是相当严重的。具体的惩罚措施如下：
All of the miner's pledge collateral and all of their power is irrevocably slashed. This miner can never again produce blocks, even if they attempt to repost their collateral.
翻译过来就是：
此攻击矿工的所有抵押全部没收，所有算力全部清零，永不恢复。同时，此矿工将不能再参与挖矿，即使重新发送抵押至网络，仍然不可。
什么意思？简单地说，就是判处死刑，没收全部财产，剥夺政治权利终生。
不坑不贪，老实做人
那么，具体哪些行为算是对共识的攻击呢？最近的讨论基本结束，共识错误的判定规则最近刚刚出台。主要有三条，直接列举如下：
双挖错误：同一矿工在同一高度产生两个区块
如下图：B4, B5 两个区块都是由矿工 C 产生的，但居于同一高度，因此违规。
跳块错误：在同一个tipset的基础上产生两个区块
如下图，B3, B4 都是在B2的基础上产生的，虽然他们不处于同一高度，仍然违规。
藏块错误：产生区块时故意丢弃上一轮自己的区块
如下图：矿工B 在上一轮产生了区块B3，同时在下一轮由产生了区块B4，但区块B4本应该在B2+B3的基础上产生，但B4抛开了B3，因此违规。
基于这三条规则，我们来看一下连弩攻击，违反了哪些部分呢？这里，其同时违反了第1条和第2条规则。当这些规则实施后，连弩攻击者将会收到最严厉惩罚。因此也就不可能对网络造成威胁了。
社区贡献，完善机制
在这个规则的完善过程中，还有些小插曲。相信不少人都读过Spec，对共识错误的理解一开始就是十分费劲的。最初非常晦涩难懂。但基本意思是大致反映了前面提到的第一条和第三条。
但是前一段时间团队急于完善设计，听取了社区的意见，把这些规则明确化。但是，可能是疏忽，机制设计中剩下上面提到的第二条和第三条。这里注意，连弩攻击尽管是在同一高度产生的，但也违反了第二条，因此，这样的规定是可以阻止连弩攻击的。但是，这里有一个大问题，允许矿工在同一个高度挖矿。
社区成员Steven对此提出质疑，最初的回答是：如果限定不能在同一高度挖矿的话，可能有些轮次有可能陷入死锁。很吓人。但是这是真的吗？
其实不然，因为矿工总是可以往前挖的，当轮不行就走下一轮，所以一定不会出现锁住的情况。此其一；其二，如果允许在同一轮挖矿，必然会给分叉的收敛带来大麻烦。我更相信这次调整遗漏这一点是一个疏忽，而不是设计如此。
很快，最新版出炉，三个方面都做了很好的规定。由于这些定义非常重要，因此，在进一步确认的过程中，Juan建议采用 dotGraph花几张图来进行阐述，使其更容易理解。这就是上面几张图的来源了。
至此，本人以为，对共识错误判定（也是共识攻击的认定）的规则基本成熟。以后会不会进一步改动。有可能，但既要做到鉴别恶意矿工，又要保护诚实矿工，在一个去中心化的网络中并不容易。比如第三个错误定义，最好的就是不能丢弃所有你看到的合法的区块，但是这个很难判定。所幸的是，基于最重链原则，大家在产生区块的时候会自发地基于最终的tipset来做，从而提升自己被网络认可的概率。这个机制本身也起到了很好的保护作用。基于这些考虑，我认为，进一步改进的空间不太大。
同时，对共识的保护，在测试网上线前就会基本实现。因此，在测试网中，这些明显的根据未实现的功能产生的攻击应该会少很多。更多的应该是发现代码的一些bug吧。
我的相关文章